1. Field of the Invention
The present invention relates to supplementary services associated with telephone service. More particularly, the present invention relates to an improved caller ID system and method.
2. Discussion of the Related Art
In households with Asian members and in companies with Asian employees, it is often necessary, or preferred, to communicate in a native language using the characters of the native language. To this end, some telephone manufactures have provided telephones with display drivers for various Asian character fonts. Therefore, setup menus and status information can be displayed and navigated in a person's native language, using the native language's characters.
Many of these households and companies also enjoy the benefits of caller ID. Caller ID records a log of incoming calls and allows for call screening. Typically, the caller ID information, transmitted in known caller ID systems, only includes Latin, Greek or Cyrillic characters. Therefore, in typical caller ID systems, when a person receives a phone call from a foreign friend or business colleague, a transliteration of the caller's name is displayed in Latin, Greek or Cyrillic characters (hereinafter referred to as “global” characters). Of course, many countries, such as Japan, Korean, Taiwan, and China, have native languages which do not use global characters. Therefore, if a name is to be displayed at all on the caller ID's display, the name will be the transliteration of the native language name into global characters. This state of the art can be disadvantageous.
When the person receiving the call understands the native language of the caller, they would often prefer to have the native name displayed on the caller ID's display. Often, the person receiving the call will be more familiar with the native language, may not be fluent in the English language or familiar with global characters, or simply may prefer the native name over its transliteration into global characters.
One solution would be to always transmit a caller's name in the native characters of the caller's native language. This solution would also have drawbacks. Often a person will call someone unfamiliar with the caller's native language. In such a circumstance, the called person's caller ID would display the native characters of the caller's name. If the called person does not understand the caller's native language, the displayed information on the caller ID would be useless. Therefore, in this circumstance, the called person would prefer a transliteration of the caller's name.
FIG. 1 is an example of a data packet containing caller ID information, in accordance with the background art. The data packet format is in accordance with signaling standards, such as ECMA-164. ECMA-164 specifies the standards for a private integrated services network (PISN) relating to the inter-exchange signaling protocol—name identification supplementary services. The contents of the ECMA standards are known to those in the art and are incorporated herein by reference.
The data packet example of FIG. 1 shows what the code set zero facility information element (IE) will look like when sending the calling name “Jirou Monden.” The data packet can be characterized by twenty members in the information element. The first member 1 identifies that the information to follow is a code set zero facility IE, in other words caller ID information.
The second member 2 identifies the length of the IE (the number of octets following this octet). In this example, the number of octets to follow is “22,” which translates into binary as 0010 0010, which means that thirty four octets will follow and constitute the complete code set zero facility IE.
Reference numerals 3–18, corresponding to the third to eighteenth members, relate to the following, respectively: Protocol length; Network facility extension (NFE) tag; NFE length; NFE contents; Interpretation application protocol data unit (IAPDU) tag; IAPDU length; IAPDU value; Protocol data unit (PDU) tag; PDU length; Invoke tag; Invoke length; Invoke contents; Operation tag; Operation length; Operation value; and Name argument tag. Reference can be had to the specifications of the ECMA standards, such as ECMA-164, if a more full understanding of these members is desired.
Member 19 identifies the length of the name argument, in other words, the number of octets to follow this octet, which will constitute the caller's name. In this example, the number of octets to follow is “0C,” which translates into binary as 0000 1100, which means that twelve octets will follow and constitute the caller's name.
Member 20 is the caller's name. In this example, the binary code would represent the name “Jirou Monden,” presented in a global character set, such as ISO-8859. The caller's name would be the last member in the data packet. This fact would be known to the system, since the length of the IE was specified in the member 2, discussed above.
As can be seen in the above example, the state of the art allows for the transmission of the caller's name in a single global character set. A person receiving the caller ID information data packet would be able to view only one version of the caller's name, i.e. the version of the caller's named encoded in the member 20.